Du stehst (mit deiner Chefin, deinem Team, deiner Firma) vor der Frage, ob ihr für das anstehende Projekt Microservices einsetzen sollt. Beim Event-Storming schälten sich sieben Core Domains, zehn supporting Domains und ebenso viele generic Domains heraus. Das schreit doch geradezu nach Microservices, oder etwa nicht? Wer heutzutage einen Monolithen erschafft, der gilt doch als digital provinziell, als letzter Mohikaner, als Ultra-Retro.
Aber macht es tatsächlich Sinn, gleich zu Beginn auf Microservices zu setzen? Oder ist es ratsamer, auf die Empfehlung von Martin Fowler und meinem Lieblingsautor Herbert Dowalil zu hören ( ausgesprochen in: Grundlagen des modularen Softwareentwurfs: Der Bau langlebiger Mikro- und Makro-Architekturen wie Microservices und SOA 2.0 (German Edition) (S.132). Carl Hanser Verlag GmbH & Co. KG. Kindle-Version.) und den Ansatz „Monolith First“ zu befolgen?
Diese Frage wird hier beantwortet und dabei definiere ich zunächst den Begriff des Microservices. Anschließend gehe ich auf dessen Use Case und die unbestreitbaren Vorteile ein, die eine Mikrodienst-Architektur mit sich bringt. Insbesondere erläutere ich die Nachteile von monolithischen Architekturen, die durch den Microservices-Ansatz abgemildert, wenn nicht sogar beseitigt werden können. Dann werden die dunkleren Kapitel aufgeschlagen: Ich bringe dir, aus der Praxis für die Praxis, die mannigfaltigen Nachteile und Fallstricke von Microservices näher. Ganz vorsichtig und behutsam, denn es sind wirklich einige „Brocken“ dabei. Wer die nicht kennt, der oder die risikiert ein Scheitern des ganzen Projekts. Abschließend gehe ich auf die aus meiner Sicht klügste Strategie bei Greenfield-Projekten ein: Monolith-First im ersten Schritt, Self-Contained-Systems im zweiten Schritt.
MICROSERVICES: WAS IST DAS?
Microservices ist ein Architekturstil, der für den Aufbau verteilter Systeme verwendet wird. Jeder Service ist ein atomarer Prozess, der - und das unterscheidet ihn im Wesentlichen von seiner Vorgängerarchitektur SOA – separat deployed wird.
Im Idealfall verfügt jeder Service zudem über eine eigene Persistierung, mithin eine eigene Datenbank oder einen eigenen Cloud-Storage, sofern der Dienst einen State halten muss. Ist er immutable, mithin stateless dann entfällt dieses Erfordernis.
Häufig ist zudem eine zeitliche lose Kopplung der Services gewünscht.
Dadurch entfallen synchron arbeitende API-Technologien wie REST, gRPC und das geschwätzige SOAP.
Stattdessen bietet sich eine asynchrone Kommunikation an, wie sie durch einen Point-to-Point- oder einen Publish-Subscribe-Channel (im Folgenden Pub-Sub) abgebildet werden kann. Ein Message Broker verwendet Pub-Sub. Diese Event-Middleware dient als Vermittlungsstelle für die Kommunikation zwischen Event-Producer und Event-Consumer. Sie ist der zentrale Punkt der Kommunikation. Ein Message Broker ist, im Gegensatz zum einfachen Message-Bus, für die Entscheidung zuständig, an wen konkret eine Nachricht zugestellt wird. So ist der Absender eines Pub-Sub-Events an einen Broker agnostisch darüber, welche anderen Endpoints diese Nachricht abonniert haben. Dies ist dann nämlich am Broker selbst konfiguriert.
Ich habe hier bewusst nicht zwischen Events und Messages unterschieden, obwohl dies bei Azure zwei verschiedene Dinge sind. In anderen Systemen werden diese Begriffe jedoch häufig synonym verwendet und als Softwarearchitekt versuche ich so oft es geht „unabhängig“ zu sein, also übernehme ich die Differenzierung von Azure in diesem Beitrag nicht, denn es geht nicht um Microsoft-Spezifika, sondern um makroarchitektonische Entscheidungen, die keinem „Vendor-Lock“ unterliegen sollen. Das passiert in der Praxis schon oft genug.
Die Services werden als Microservices bezeichnet, weil sie in der Regel (nicht notwendigerweise auf LoC bezogen!) klein sind. Sie konzentrieren sich auf die Ausführung einer isolierten Aufgabe in einem verteilten System.
Seperation of Concerns lässt grüßen.
MICROSERVICES: VORTEILE & USE CASES
USE CASES
Microservices bieten sich vornehmlich an, wenn es sich um eine Software-as-a-Service-Applikation (SaaS) handelt und es genug Entwickler/innen gibt, sodass sich der massive Deployment-Overhead (Mikrodienste werden fast immer per Infrastructure as Code in Replika-Cluster wie Azure Service Fabric, AKS, Kubernetes und ähnliches deployed) in Form von Produktivitätszuwachs amortisiert.
Warum SaaS-Applikationen?
Von diesen Produkten wird in der Regel erwartet, dass sie rund um die Uhr funktionieren, was bei der Einführung von Änderungen eine Herausforderung darstellt. Die unabhängige Releasefähigkeit von Mikrodienst-Architekturen ist ein Segen in diesem Bereich.
Außerdem können die Mikrodienste je nach Bedarf nach oben oder unten skaliert werden.
Microservices bieten zudem klare Vorteile für Organisationen, die ihren Kunden Dienstleistungen über eine Vielzahl neuer Kanäle anbieten möchten. Ich studiere ja gerade an der IU (Zeitpunkt: 2022/12/12 – 17:11; mache dort meinen Master in AI, siehe https://www.wackyworld.de/artificial-intelligence-studies), und die Lerninhalte gibt es klassisch per PDF, aber auch per Web-App auf dem Desktop, per Mobile-App für IoS und Android und wer weiß, vielleicht auch bald lediglich per Audio-File als Podcast-Feed. Diese Output-Diversität lässt sich mit einer Microservice-Architektur gut managen.
Allen voran ist eine Mikrodienst-Architektur eine solche, die Ihnen bei der Weiterentwicklung Ihres Systems viel Flexibilität (in Form von Skalierung) bietet.
Diese Flexibilität hat natürlich ihren Preis wie alles im Leben.
NACHTEILE VON MONOLITHISCHEN ARCHITEKTUREN, DIE MIT MICROSERVICES ÜBERWUNDEN WERDEN KÖNNEN UND SOMIT ALS DEREN VORTEILE GELTEN
Ein großes Problem bei Monolithen ist oft das, was ich „Spinnennetzeffekt“ nenne. Du erzeugst am Ende des Netzes eine Vibration, aber die Bewegung ist überall zu spüren. Für die Spinnen ein überlebenswichtiger Vorteil, für uns Softwareentwickler ein Riesennachteil. Selbst eine einfache Codeänderung in einem der Module kann eine wichtige Funktion in anderen Modulen beeinträchtigen. Wir müssten danach wieder alle Unit-Tests, Integrationstests und möglicherweise auch UI-Tests durchlaufen lassen, um sicherzugehen, dass der Spinnennetz-Effekt uns nicht einen nachher nur schwer zu lokalisierenden Bug beschert hat. Ich kenne Unternehmen, da laufen die Integrationstests über Nacht. Und ein Lauf nimmt mehr als 10 Stunden Zeit in Anspruch.
Die enge Kopplung aller Bausteine stellt eine weitere Herausforderung dar: Wenn wir eine solche Software ausführen oder kompilieren, müssen alle Bausteine verfügbar sein, sonst schlägt der Build fehl. Monolithische Architekturen enthalten meist mehrere Assemblies (= seperate Deployment-Artifakte). Zur Compiletime mag eine Trennung vorliegen, aber zur Laufzeit werden alle Bausteine wieder zusammengefügt wie die Teile eines Puzzles und - unter einem gemeinsamen Prozess vereint - ausgeführt.
Daraus resultieren drei wesentliche Probleme:
1. Gerade bei Webanwendungen kommt es häufig vor, dass Frameworks (wie React und / oder Angular) in einer neuen Version verfügbar sind. Wenn dann ein Upgrade notwendig ist, etwa aus Sicherheitsgründen, ist ein separiertes Aktualisieren häufig schwieriger als bei Mikrodiensten da die Laufzeitabhängigkeiten Probleme bereiten könnten. Häufig wird synchron über REST und Co. kommuniziert, da bleibt keine Zeit für temporale Entkopplung wie es bspw. mit einem Message-Broker-System möglich wäre.
2. Das Deployment einer solchen Anwendung würde zu einer weiteren Herausforderung. Bei der Bereitstellung müssten wir sicherstellen, dass jede Komponente ordnungsgemäß bereitgestellt wird. Wenn wir das nicht tun, könnten wir in unseren Produktionsumgebungen mit einer Menge Probleme konfrontiert werden.
Stell dir vor, was passiert, wenn in der Monolithen-Middleware 20 oder mehr Services heranwachsen. Es bedeutet, dass die Weiterentwicklung dieser Services ziemlich sicher mit unterschiedlicher Geschwindigkeit abläuft. Wenn man so viele Services hat, hat man auch viele Clients, die unsere Services konsumieren.
Wie aber sieht das Deployment aus, wenn mehrere Services mehrere Versionen anbieten müssen, weil die Clients nicht migriert werden können?
Man müsste in solchen Fällen das ganze System als Kopie (häufig auch mehrere Kopien) in verschiedenen Versionen betreiben.
Was passiert, wenn nur ein Service skaliert werden muss, weil die Last zu hoch ist? Es gilt das ganze System zu skalieren, womit die Betriebskosten unnötig steigen.
Wie sieht es mit Migrationen (oder Innovationen) aus?
Würde man einen Service auf eine neue Version oder eine neue Technologie heben wollen, so ist es bei .NET oft so, dass man dann auch alle anderen Dienste auf die neue Runtime heben müsste. Ich hatte so einen Fall schon mal gehabt und wir haben auf Wunsch des Product Owners mit linearer Regression die Zeit (nicht wie sonst die Komplexität) geschätzt, was bei dem Vorhaben vernünftig war, denn es ging um verdammt hohe Kosten. Soweit ich mich entsinne kam irgendetwas mit 12 Sprints a 3 Wochen heraus. Nur für die Migration eines schwerfälligen .NET 4.5-Monolithen auf das damals aktuelle .NET Core. Die herunterklappenden Kinnladen des Product Owners werde ich nie vergessen, nachdem wir unser Schätzergebnis verkündet hatten. In meiner Zeit wurde die Migration nicht mehr durchgeführt.
Was meinst du, warum so viele kommerzielle Tools, noch immer die alten .NET-Frameworks verwenden?
3. Als ich damals bei einem meiner früheren Arbeitgeber angefangen habe, wurde ich einem Team zugeordnet, das einen klassischen Monolithen „bearbeitete“. Ein Satz aus dieser Zeit wird mir nie aus dem Gedächtnis weichen. Ich fragte einen der Jungs, wie lange er denn gebraucht habe, bis er sich in der Codebase zurechtgefunden habe. Seine Antwort:
„Also 6 Monate, habe ich schon gebraucht, mach dir keine Sorgen, Jens, ich kenne Kollegen, die haben nach 2 Jahren noch immer nicht alles gesehen.“.
Zack, das saß. Ich kam mir fortan vor, als ob ich an der Ausgrabung einer griechischen Tempelstätte beteiligt wäre.
Meist kommt auch noch erschwerend hinzu, dass niemand eine aktuelle Dokumentation besitzt. Hier greift dann die Broken-Window-Theorie. Lohnt sich eh nicht mehr.
Oder: Frag Atze, der weiß das.
MICROSERVICES: NACHTEILE & FALLSTRICKE
Ich bin ein großer Fan von Microservices, bitte nicht falsch verstehen. Aber ich bin ein noch größerer Fan von Komplexitätsvermeidung und / oder -reduzierung.
Ich halte es mit Einstein:
Mache die Dinge so einfach wie möglich. Nur nicht einfacher!
Und Microservices bringen immer mehr Komplexität in – Achtung aufpassen – Bereichen mit sich, in denen sich viele Entwickler/innen nicht so gut auskennen. Auf Code-Entwicklerlevel sind zu nennen: Event-Sourcing, CQRS, Sagas und CAP-Theorem-bedingten Problemen. Auf DevOps-Level sind zu nennen: Server-Templating-Tools wie Docker, Cluster-Orchestrierer wie Kubernetes, IaC-Tools wie Azure Bicep und / oder Terraform und / oder ARM.
Während die berühmten „natürlich gewachsenen“ Monolithen oft insgesamt, mithin quantitativ komplexer sind, so ist doch den meisten Entwickler/innen klar, wie sie hier gegensteuern können. Erhöhung der Anzahl der Abstraktionen, Dependency Injection, Vermeidung von zyklischen Abhängigkeiten etc.
Bei Microservices ist es nicht selten so, dass am Anfang keiner weiß, wie die Lösung des Problems aussehen könnte und deshalb sind viele PBIS (Product Backlog Items) oftmals zunächst auf „Analyse“ gerichtet. Die Folge: Es kann nichts geschätzt (estimated im Sinne von Scrum) werden, der „Kunde“ des Scrum-Teams muss ständig hingehalten werden und nicht selten fühlt man sich als Entwickler/in mit den gefühlt tausend neuen Technologien überfordert und arbeitet ständig mit Zeitdruck im Nacken.
Na, kommt dir das bekannt vor?
Fangen wir mal von vorne an:
8 FALLACIES OF DISTRIBUTED SYSTEMS HOCH 2
Zu den 8 Fallacies, guckst du hier: https://www.wackyworld.de/post/the-big-picture-behind-cloud-architecture-teil-1-8-fallacies-of-distributed-systems
Als ehemaliger Boxer und jetziger (Altherren-)Krav-Maga-Kämpe, weiß ich (aus meinem Schmerzgedächtnis), dass ein Leberhaken erheblich intensivere Schmerzen verursachen kann als ein Kinntreffer.
Distributed Systems (im folgenden DS) sind die Leberhaken im Kampf gegen Komplexität.
Und Microservices sind die Leberhaken geschlagen von den Klitschko-Brüdern. Von beiden gleichzeitig, wohlgemerkt.
D.h. die Pain, die ohnehin schon bei DS auftritt, wird bei einer Microservice-Architektur verzehnfacht. Alle Probleme, welche der Bau eines verteilten Systems mit sich bringt, wirst du hier in verschärfter Form haben. Jede Art von Netzwerkproblem kann sich nachteilig auf das System auswirken. Zudem stellt die umfangreiche Netzwerkkommunikation einen neuen möglichen „Point of Failure“ dar.
Daten, die im sagenumwobenen „natürlich gewachsenen“ Monolithen innerhalb eines einzigen Prozesses hin- und hergereicht wurden, müssen in einem Microservice-System serialisiert, übertragen und über Netzwerke deserialisiert werden. Dateninkonsistenz, lange Latenzzeiten und was sonst noch so alles an verteilten Systemen nervt, kann bei Mikrodiensten zu schwer diagnostizierbaren Fehlern führen und schlimmstenfalls ganze Projekte in den Abgrund reißen.
Wer hier ohne vertiefte Kenntnisse der Microservice-Architektur blauäugig an die Sache rangeht, wird ein hohes Lehrgeld zahlen.
Aber dir kann das nicht passieren, denn du liest ja meinen Blogartikel ;)
MICROSERVICE-TECHNOLOGY-OVERFLOW GEPAART MIT MANGELNDER ERFAHRUNG
Wer dachte, nur im Frontend gäbe es jede Woche ein neues Framework, der / die irrt. Es ist nicht nur so, dass es bereits einen ganzen Zoo von neuen Technologien gibt, die es erleichtern sollen, Microservices einzuführen und / oder zu betreiben. Nein, es kommen auch ständig neue Exotentierchen hinzu. In den Zoo.
Es gibt Early-Adopter-Entscheider, die glauben, dass mit der Einführung von Microservices gleich einen bunter Strauß an frisch geschlüpften Technologien auf die Entwickler/innen losgelassen werden sollte.
Die kriegen das schon hin.
Da wird Datenreplikation per Cluster (Kubernetes und Co.) „angeordnet“ und Horst-Günther, der Senior-Entwickler, der die berechtigte Frage stellt, ob dies denn bei fünf Services angebracht sei, zum Bremser degradiert.
Claudia leidet mit. Sie hat es gewagt, vor einer Woche das hochkomplexe Messaging-System in Frage zu stellen. Sie ist allerdings auch erst auf Seite 2700 der Getting-Started-PDF angekommen.
Ein Start-up, für das ich gearbeitet habe, hat dies betreffend einen Vorteil gehabt, der gleichzeitig zeigt, was für ein Hagelschauer an neuen Technologien auf die Entwickler/innen niederprasseln kann. Das Team hatte sechs Monate Zeit (Vollzeit), sich in das Thema Microservices einzuarbeiten, bevor sie angefangen haben zu coden. Und ich spreche hier nicht von Junior-Developer/innen! Sechs Monate Vollzeit!
Und damit waren noch lange nicht alle Probleme im Vorfeld gelöst, denn viele entstanden erst nach der Inbetriebnahme, wie es bei jedem Softwareprojekt der Fall ist.
Es besteht stets die Gefahr, dass der Reichtum an neuem Spielzeug zu einer Form von Technologiefetischismus führen kann. Nach dem Motto :
„Jetzt fangen wir ohnehin mit Microservices an, dann können wir auch gleich Framework X, Clusterlösung Y und Cloud-Service Z auspropieren.“.
Vergessen wird dabei oft, dass die Zeit für das Ausprobieren, die Zeit verkürzt, die du für die Auslieferung von Funktionen an deine Benutzer hast.
Wenn du mit der Einführung von Mikrodiensten beginnst, solltest du dich auf das Wesentliche konzentrieren: Das sind nach meinem Dafürhalten, Lösungen, die vor allem die nachfolgend erwähnten Probleme abmildern, u.a. Probleme im Zusammenhang mit Datenkonsistenz, Latenzzeiten und Servicezuschnitt.
Wenn keine Einarbeitungszeit zur Verfügung steht, ist es unabdingbar, dass ausreichend Entwickler/innen verfügbar sind, die Erfahrung mit den verwendeten Technologien und der Architektur haben. Ansonsten werden Domänen falsch zerstückelt (Event Storming, was ist das?), zu früh Clusterlösungen eingesetzt (bei 3 Diensten ist kein Kubernetes nötig!) und / oder – was ich für das schlimmste halte – Kolleg/innen überfordert. Das Resultat ist oft Krankheit oder (innere) Kündigung.
TESTING
Unit-Tests werden kein Problem darstellen, wohl aber dienstübergreifende Tests.
Je größer die Codebase wird, desto weniger „Erkenntnisgewinn“ wirst du mit zunehmender Testdichte erzielen. Die Tests werden zwar mehr kosten, aber sie werden dir nicht mehr das gleiche Maß an Vertrauen vermitteln können wie in der Vergangenheit. Weil der Deployment-Overhead bei Microservices die „Testrendite“ ausbremsen wird.
LATENZZEIT
Mit einer Mikrodienst-Architektur kann die Verarbeitung, die früher lokal auf einem Prozessor durchgeführt wurde, nun auf mehrere separate Mikrodienste aufgeteilt werden. Informationen, die im Reich der Monolithen innerhalb eines einzigen Prozesses flossen, müssen nunmehr serialisiert, übertragen und über Netzwerke wieder deserialisiert werden.
All das kostet Zeit.
Und Zeit ist Latenz.
EVENTUELLE DATENKONSISTENZ
Eventuelle Konsistenz (EK) ist ein Konsistenzmodell, das in der verteilten Datenverarbeitung verwendet wird, um eine hohe Verfügbarkeit zu erreichen. Es garantiert, dass alle Zugriffe auf ein Datenelement den zuletzt aktualisierten Wert zurückgeben, wenn keine neuen Aktualisierungen vorgenommen werden.
Hierzu schreiben [Edlich+11] (BASE ist das Synonym zu Eventual Consistency)
„Bei BASE dreht sich im Gegensatz zu ACID alles umVerfügbarkeit.Konsistenz wird der Verfügbarkeit bei BASE untergeordnet.Wo ACID einen pessimistischen Ansatz bei der Konsistenz verfolgt, ist BASE ein optimistischer Ansatz, bei dem Konsistenz als ein Übergangsprozess zu sehen ist und kein fester Zustand nach einer Transaktion.Daraus entsteht ein völlig neuartiges Verständnis von Konsistenz:Eventually Consistency.
Systeme, die nach BASE arbeiten, erreichen auch irgendwann den Status der Konsistenz, die Betonung liegt dabei aber aufirgendwann. Infolgedessen wird Konsistenz erst nach einem Zeitfenster der Inkonsistenz erreicht und nicht unmittelbar nach jeder Transaktion.“
EK wird häufig in verteilten Datenspeichern verwendet, in denen niedrige Latenzzeiten und hoher Durchsatz erforderlich sind. Das Lehrbuchbeispiel sind Cloud-basierte Systeme. Datenbankmanagementsysteme (DBMS), die eventuelle Konsistenz verwenden, sind Amazons DynamoDB und Apache Cassandra.
Der Übergang von einem monolithischen System, in dem die Daten in einer einzigen Datenbank gespeichert und verwaltet werden, zu einem viel stärker verteilten System, in dem mehrere Prozesse den Zustand in verschiedenen DBMS verwalten, bedeutet ein Abrücken vom ACID-Paradigma, das bei relationalen DBMS vorherrscht.
A.C.I.D. steht für Atomicity, Consistency, Isolation und Durability. Es handelt sich um eine Reihe von Eigenschaften, die garantieren, dass Datenbanktransaktionen zuverlässig verarbeitet werden.
Atomizität erfordert, dass jede Transaktion „alles oder nichts“ ist: Wenn ein Teil der Transaktion fehlschlägt, schlägt die gesamte Transaktion fehl und der Zustand der Datenbank bleibt unverändert.
Die Konsistenz gewährleistet, dass jede Transaktion die Datenbank von einem gültigen Zustand in einen anderen bringt. Alle Daten, die in die Datenbank geschrieben werden, müssen gemäß allen definierten Regeln gültig sein, einschließlich Constraints, Kaskaden, Triggern und jeder Kombination davon.
Die Isolierung stellt sicher, dass die gleichzeitige Ausführung von Transaktionen zu einem Systemzustand führt, der sich ergeben würde, wenn die Transaktionen seriell, d.h. nacheinander, ausgeführt würden.
Die Dauerhaftigkeit stellt sicher, dass eine Transaktion, die an die Datenbank übertragen wird, nicht verloren geht. In einer relationalen Datenbank beispielsweise werden die Änderungen in der Datenbank gespeichert, sobald eine Transaktion bestätigt wurde, und bleiben auch bei einem Systemausfall erhalten.
Während du dich in der Vergangenheit auf Datenbanktransaktionen zur Verwaltung von Zustandsänderungen verlassen hast, musst du jetzt umdenken.
Du musst dich mit Konzepten wie Sagas und der oben erwähnten EK vertraut machen. Eine weitere Herausforderung, ist die Frage, wie man an Verarbeitung großer Datenmengen über Servicegrenzen hinweg herangehen sollte.
Dies ist ein weiterer, extrem wichtiger Grund, vorsichtig zu sein und nicht gleich die Mikroservice-Kettensäge anzuschmeißen.
HOHER AUTOMATISIERUNGSLEVEL
Microservices erfordern ein hohes Maß an Automatisierung, damit die Teams schnell Änderungen vornehmen und diese bereitstellen können, ohne jeden Dienst manuell verwalten zu müssen. Dazu gehört die Automatisierung von Prozessen wie Tests, Bereitstellung und Überwachung. Die Automatisierung trägt auch dazu bei, dass alle Dienste ordnungsgemäß laufen und Probleme schnell erkannt werden können. Darüber hinaus kann die Automatisierung zur Kostensenkung und Effizienzsteigerung beitragen.
MONITORING & REPORTING
Max Monolith war noch leicht zu überwachen, während Mona Microservice und ihre 1000 Service Kinder nicht selten unter dem Radar verschwinden.
Auch hier müssen wieder neue Ansätze her. Bspw. könnte man Streaming-Services einsetzen, um große Datenströme in Echtzeit zu überwachen.
In Azure gibt es zur Erfassung diverser Metriken viele gute Werkzeuge (, die es sicher auch bei AWS und bei Google Cloud gibt), wie Azure Monitor, Log Analytics, Power BI, Application Insights etc.
CROSS CUTTING CONCERNS
Cross-Cutting-Concerns oder auch Querschnittsthemen sind Aspekte der Softwareentwicklung, die sich über mehrere Schichten und Komponenten einer Anwendung erstrecken. Zu diesen Aspekten gehören Protokollierung, Authentifizierung, Autorisierung, Caching und Überwachung.
Das Problem mit übergreifenden Belangen in Microservices ist, dass sie in einem verteilten System schwer zu implementieren sind. Das liegt daran, dass jeder Dienst seine eigenen Anforderungen an Authentifizierung, Protokollierung usw. hat und es schwierig sein kann, diese verschiedenen Anforderungen in ein zusammenhängendes System zu integrieren.
Außerdem können Änderungen an einem Dienst unbeabsichtigte Folgen für andere Dienste haben, wenn die übergreifenden Belange nicht ordnungsgemäß verwaltet werden.
Schließlich kann die Fehlersuche und -behebung bei Problemen, die mehrere Dienste betreffen, schwierig sein.
LÖSUNGSANSATZ: MONOLITH FIRST UND DANACH SELF CONTAINED SYSTEMS
MONOLITH-FIRST (MF)
Der „Monolith first“-Ansatz für Microservices ist eine Methode zur Entwicklung von Software, die mit einer monolithischen Gesamtarchitektur beginnt und diese dann schrittweise in kleinere, verteilte Dienste umstrukturiert. Auf diese Weise können die Entwickler mit einer möglichst einfachen Architektur beginnen und dann nach und nach die Komplexität erhöhen, je nach Bedarf.
VORTEILE DES MF-ANSATZES
Durch das Refactoring des Monolithen in kleinere Dienste können Unternehmen langfristig ein skalierbareres und robusteres System erreichen.
Es ermöglicht auch eine schnellere Entwicklung, da der mit der Erstellung mehrerer Dienste verbundene Aufwand von Anfang an entfällt.
Der MF-Ansatz stellt auch sicher, dass alle Funktionen der Anwendung getestet werden und als eine Einheit funktionieren, bevor sie in einzelne Dienste aufgeteilt werden. Dadurch wird das Risiko der Einführung von Fehlern oder anderen Problemen verringert, die bei der Integration mehrerer Dienste auftreten können.
Kurzum: Alle vorher erwähnten Nachteile können sehr stark dadurch abgemildert werden, dass man den berühmten ersten konfuzianischen Schritt mit einem Monolithen beginnt.
STUFE 2: SELF CONTAINED SYSTEMS (SCS)
Ein SCS, mithin ein in sich geschlossenes System ist ein Softwaresystem, das so konzipiert ist, dass es unabhängig von anderen Systemen funktioniert. Das bedeutet, dass das System so entworfen wurde, dass es alles enthält, was es zum Funktionieren braucht, von der Benutzeroberfläche über die Datenspeicherung bis hin zur Anwendungslogik.
Aber das ist noch nicht alles. Bei SCS handelt es sich um einen Ansatz, der ähnliche Philosophien umsetzt wie jene, auf denen üblicherweise Microservice-Architekturen aufbauen. Es wird die Systemlandschaft ebenfalls in Strukturen aufgeteilt, in die Systeme. Die konkreten Architekturen der einzelnen Systeme können sich dabei – und jetzt kommt die Besonderheit – voneinander unterscheiden. So kann ein System aus Microservices aufgebaut sein, während ein anderes eine monolithische Architektur umsetzt.
Mittels SCS kann man sich somit in einem 2. Schritt an eine vollständige Microservice-Architektur herantasten.